The present invention relates to the field of digital computers. In particular, the present invention provides a method and apparatus for waiting the bus in a digital computer to allow a slow bus module to respond to bus signals and data.
Digital computers typically consist of a central processing unit (CPU) module, a memory module, a disk controller module and other input and output modules all connected together by one or more busses. FIG. 1 shows a simplified computer system utilizing multiple bus modules connected to a bus. The modules communicate with each other over the bus with the communication consisting of the transfer of address, data and status signals.
For the computer modules to communicate with each other, each must adhere to the protocol of the bus. This protocol consists of timing and electrical specifications which determine how the bus is used. Included in the bus protocol is a wait mechanism that allows a module to "wait" the bus. A wait mechanism is required because a bus module cannot always provide or accept data at the normal timing specified by the bus protocol. Events such as memory refresh, or a delay in obtaining cache coherehey check results in a multiprocessor system are common reasons to wait a bus. By asserting a wait signal, a bus module can effectively stop the transfer of valid data on the bus until the module can continue with the bus transaction.
In the discussion below the terms "good data", "bad data", "valid data" and "invalid data" are used. "Good data" refers to data that is correct while "bad data" refers to data that is incorrect. An example of bad data would be a data word with one or more bits incorrect because the driver was unable to supply the proper bits during the current bus cycle. "Valid data" is data that is both good and present on the bus during a time the bus protocol allows the data to be used. "Invalid data" is data that is either bad or data that is good but present on the bus at a time the bus protocol does not allow the data to be used.
Also, a driver module refers to a module that is driving address, data or status signals on the bus. A receiver module is a module that receives the address, data or status signals driven on the bus by the driver module.
Shown in FIGS. 2A and 2B are the timing diagrams of a prior art bus without a wait state and with a wait state respectively. In FIG. 2A, a wait command is not asserted by a module therefore the data represented by "DATA" is not delayed and is valid during the T.sub.1 bus cycle. In FIG. 2B a bus module has asserted a bus wait command and the data on the bus during the T.sub.1 bus cycle is invalid. Data on the bus will continue to be invalid until the wait command is released by the asserting bus module. When the wait command is released, valid data will be driven onto the bus during the bus cycle immediately following the release of the wait command. In the example shown in FIG. 2B, valid data is driven onto the bus during the T.sub.2 bus cycle. If the driver module needed to wait the bus, then the data available on the bus during the T.sub.1 bus cycle would not be good data as the driver did not have the data available. However, if a receiver module waited the bus, then the data available during the T.sub.1 bus cycle may be good data but considered invalid data by protocol definition. The driver module would drive good data onto the bus during the T.sub.1 bus cycle and hold the same good data on the bus through the T.sub.2 bus cycle.
One problem with the prior art bus protocol and wait mechanism is a module must recognize a wait command has been asserted and respond almost instantly. As shown in FIG. 2B, a module must recognize the wait command was asserted during the T.sub.1 bus cycle and respond appropriately during the start of the T.sub.2 bus cycle. This response time was sufficient when computers operated at 8 megahertz (MHZ). Today, with computers operating at 50+ MHZ, a protocol requiring the bus modules to recognize a wait command and respond at the start of the next bus cycle is not practical due to speed limitations of the integrated circuits used by the modules.
To increase the time a module has to respond to a wait command, a protocol shown in FIG. 2C can be used. This protocol requires a bus module to assert a wait command one bus cycle before the bus cycle to be waited. As shown in FIG. 2C, the wait command is asserted during T.sub.O and therefore the data on the bus during bus cycle T.sub.1 is invalid. During bus cycle T.sub.2 the data on the bus is valid. While this protocol allows more time for modules on the bus to respond to a wait command, the extra time still may not be sufficient. Also, there is a performance cost to increasing the response time by forcing a module to assert a wait command earlier than T.sub.0 (for example assert wait at T.sub.1) as the module asserting wait may not definitely know a wait is needed earlier than T.sub.0. If a module asserts a wait when it is not needed, a bus cycle is wasted and the performance of the computer is degraded.
Therefore, what is needed in the industry is a protocol method and apparatus for waiting a bus without needlessly degrading the performance of the computer and while allowing modules on the bus sufficient time to recognize and respond to the wait command.